Reactive applications relate to a class of applications that are event-driven and configured to operate upon detection of events. The exact timing and content of such events are not usually known in advance. Many tools in different areas have been built to detect events, and to couple their detection with appropriate actions. These tools exist in products that implement active databases, event management systems, the “publish/subscribe” mechanism, real-time systems and similar products. Most current reactive systems respond to a single event.
A known problem in many reactive applications is the gap between the events that are supplied by an event source and situations to which the clients are required to react. In order to bridge this gap, the client must monitor all the relevant events and apply an ad hoc decision process in order to determine whether the conditions for reactions have been met.
U.S. Pat. No. 6,208,720 (Curtis et al.) issued Mar. 27, 2001 and entitled “System, method and computer program product for a dynamic rules-based threshold engine” discloses a configurable and scalable rules-based system for processing event records including a core infrastructure and a configurable domain-specific implementation. The domain-specific implementation is provided with user specific data and rules. The core infrastructure includes an event record enhancer which enhances events with additional data and a threshold detector which determines whether an enhanced event record, alone or in light of prior event records, exceeds one or more thresholds. The enhancer can access external databases for additional information related to an event record. The threshold detector selects one or more threshold rules from a database of threshold rules for applying to the enhanced event records. Where enhanced event records are in the form of feature vectors containing features and feature values, the threshold detector selects one or more threshold rules based upon the features or feature values in the vector. Where the feature vector includes a threshold for a feature value, the threshold detector tests the feature values against the threshold. The threshold detector may access prior event records in order to apply one or more threshold rules.
Thus, while such a system employs an external database that is used by the thresholding engine, the external database is used to store threshold rules that may be modified dynamically during run-time. The threshold detector receives enhanced event records and selects one or more threshold rules from the threshold database. The threshold rules indicate how the thresholding engine must react to specified events. For example, a system for detecting tele-communication fraud may require that event records be monitored in order to detect when a threshold has been exceeded. The event could be calling a targeted telephone number and the threshold could be set to a number of calls so as to warn an operator when more than this threshold number of calls is made to the targeted telephone number. Thus, although the threshold extracted from the database sets a limit to a specific event it does not constrain the event in any way. That is to say the event of dialing the targeted telephone number occurs regardless of the threshold and it is only after the event has occurred that correlation with the database is required, in order to determine whether the event is significant or not.
U.S. Pat. No. 6,006,016 (Faigon et al.) issued Dec. 21, 1999 discloses a method and apparatus for correlating faults in a networking system. A database of fault rules is maintained along with and associated probable causes, and possible solutions for determining the occurrence of faults defined by the fault rules. The fault rules include a fault identifier, an occurrence threshold specifying a minimum number of occurrences of fault events in the networking system in order to identify the fault, and a time threshold in which the occurrences of the fault events must occur in order to correlate the fault. Occurrences of fault events in the networking system are detected and correlated by determining matched fault rules which match the fault events and generating a fault report upon determining that a number of occurrences for the matched fault rules within the time threshold is greater than or equal to the occurrence threshold for the matched fault rules.
In such a system a fault constitutes an event that must be trapped and monitored. Here, too, only those faults whose frequency exceeds a certain threshold are of interest but no access to an external database is disclosed.
U.S. Pat. No. 5,748,098 (Grace) issued May 5, 1998 discloses a method event correlation method for a general purpose event analyzer, which records events historically in time windows and calculates correlations based on probability of events occurring together in same window. Simultaneous events reported to an equipment management system are compared with historical data in order to establish whether there is a relationship between the events. Historical data is used to determine the probability of the events occurring independently simultaneously. If this probability is below a predetermined threshold this will suggest that the events are not independent, but are related. The historical database may be updated by further event occurrences as they are reported to the equipment management system, thereby enlarging the database to make the results more statistically accurate. Events may be reported to the system automatically or by human agency. To allow for systematic delays in event reporting, alarms from one source may be compared with alarms from another source occurring a fixed time later or earlier.
Thus, this reference also discloses use of an external database, although in this case it is used for storing historical data so as to determine whether simultaneous events (occurring within a temporal window) are mutually dependent or not. Thus, here again, the database allows events to be analyzed after their occurrence but is not used to constrain the events, which have already occurred.
In summary, current event management tools process data that is ‘pushed’ towards them. That is, they obtain all the needed information as incoming events. This forces limitations on their capabilities. When part of the needed information is not given by the incoming events there are two possibilities to overcome it.
One solution is to periodically capture the state of the needed information in the database, and send it as events to the system. This solution has two main drawbacks: (1) it can enlarge dramatically the communication traffic and result in a large volume of redundant information that is being sent and processed; (2) the data that is being supplied does not necessarily remain accurate when it is being used.
A second solution is to detect situations based on partial knowledge. This reduces the effectiveness of the tool, and obliges the client to complete the detection.
It would therefore be advantageous to combine the information that is given by incoming events together with the possibility to access a database if some additional information is needed.
By way of example, consider a situation where a preferred client wishes to be alerted if at least two out of four stocks have risen by 5 percent since the start of the trading day, where the incoming events are stock quotes and the information on preferred customers is kept in a bank database. Another example might be a client wishing to activate an automatic “buy or sell” program if, for any stock that belongs to a predefined list of stocks that are traded in two stock markets, there is a difference of more than 5 percent between the values of the stock in different stock markets, where the time difference of the reported values is less than 5 minutes (“arbitrage”), and the client has sufficient funds in his or her bank account. The incoming events are stock quotes from various stock markets and the client bank account is accessed from the bank database.
The above-referenced prior art systems cannot address this need. It would therefore clearly be desirable to provide an improved mechanism for integrating an event with external data that is used in combination with one or more incoming events to define a situation to which an application must react. A situation is thus a reactive entity that receives events as input, combines composition filtering, content filtering and context filtering, and detects situations as output. The composition filtering is defined by composition operators.